而在什麼情況選擇 E2E 測試呢？這個答案可能在不同的情境有不同的答案，不過可以分享一下我的情境，我目前的公司屬於新創公司，需求還在快速迭代的情況下，我們的測試選擇是將 Unit test 覆蓋在基礎核心的共用組件，這類組件有些需要依賴 API 的也會使用 MSW 來 Mock API。

而「頁面組件」以及「特定頁面專用組件」就比較少進行單元測試，與之相對的是頁面會使用 E2E test 來進行確保。

這樣選擇的原因在對於還在持續開發中、不成熟的專案來說，為所有的組件撰寫 Unit test 背後是有巨大的維護成本的，而且 Unit test 並不能證明產品目前對使用者來說沒有任何問題，因此我認為在專案的開發早期，E2E test 比 Unit test 更有幫助。

越大的範圍 === 越多的不確定

不過撰寫 E2E 測試對前端來說，因為牽扯到 API 也會有更多測試失敗的可能。

例如有些 mutation 打過去之後，後端需要再串第三方服務，或是公司自己的其他服務，人工操作的時候不會發現什麼問題，但 E2E 跑腳本操作太快，還會同時跑好幾個 worker 執行，可能會出現上一步的動作還沒完成就又打請求，然後服務就死了……

常常變成還要為這種事情多去加 delay，而且這種問題沒失敗之前通常也不會發現，寫測試的過程就會一直測試、失敗、調整、測試、失敗、調整.....

而且因為牽扯到後端，有時還會有請求限制，有些高負荷的 API 打的密度高會被 ban，只能一個一個跑時間就會導致測試時間拖很長。

雖然這種狀況在某些層面也可以視為是一種壓力測試，可以發現一些邊緣情境，但不能否認的是撰寫 E2E test 並不只是單純的撰寫腳本，反而需要與團隊有大量的溝通。